Summary

Fixes the landing-variant A/B test on the wp-admin welcome page, which was stuck on the free-plus fallback for every visitor (issue #1188).

• New Services\Feature_Flags — resolves landing-variant server-side, locally, using PostHog's standard consistent-hash algorithm (the same one the server SDKs' get_all_feature_flags() uses). No network call, no secret.
• Landing_Profile::get_functional_data() now injects bootstrap_flags into the always-present, consent-independent functional data, keyed by the per-site anon_id.
• Menu welcome page — removed the early posthog.init() + identify() inline script and the redundant DOM CTA tracker. The wp-admin-landing bundle now solely owns PostHog init and the flag-before-identify ordering.

Root cause (two compounding bugs)

1. The self-hosted PostHog flags endpoint is broken for the public token. Verified against ph.wcpos.com: POST /capture/ → 200 (token valid), but POST /flags/?v=2&config=true → 401 "API key invalid" and POST /decide/?v=3 → 403 CSRF. So posthog-js never resolves the flag over the network — hence zero render_source:flag events across all 337 visitors (a 500 ms timeout would have let some through; zero means systematic endpoint failure). This is an infra bug that still needs a separate fix — see "Follow-ups". The team's get_all_feature_flags() "works" only because it's the Python SDK doing local evaluation with a personal API key, never touching /flags.
2. The plugin identified too early. The welcome page called posthog.init + identify(user_uuid) in an inline script that runs before welcome.js. Both PostHog instances share the ph_<token>_posthog localStorage key, so this flipped the bundle's hasPersistedIdentity() gate and poisoned the anon-bucket exposure (spec §5.1 flag-before-identify).

The issue's suggested fix (bootstrap inside the plugin's posthog.init, server-side /decide) is not viable: that init is consent-gated so it never runs for the anonymous majority, and /decide is the broken endpoint. This PR instead delivers the variant through the always-present landing data and removes the plugin's PostHog involvement on that page entirely.

Design decisions (preserve through rebases)

• Local consistent-hash instead of a /decide network call — deliberate, because the self-hosted /flags//decide endpoints reject the public token (see root cause). Local hashing replicates PostHog's exact algorithm (verified against a reference implementation — all 6 test vectors match), so assignment agrees with get_all_feature_flags() and is independent of the broken endpoint.
• Removed the welcome-page posthog.init/identify and landing_tracking_inline_script() — not dead-code cleanup. The bundle owns PostHog; the plugin's early init poisoned shared localStorage and the DOM CTA tracker double-fired upgrade_cta_clicked against the bundle's own React tracking. Menu::get_posthog_inline_script() is kept — still used by the Settings and wc-Analytics pages.
• bootstrap_flags is consent-independent — it's anonymous (random per-site UUID, no PII) and the experiment runs pre-consent by design, so it ships in the functional tier, not the consented tier.
• @since 1.9.7 on the new filter assumes the next patch release off 1.9.6 — adjust if the release is numbered differently.

Companion PRs / cross-repo

• landing-variant A/B test not splitting — all visitors get free-plus fallback wp-admin-landing#39 — the bundle must read data.bootstrap_flags into posthog.init's bootstrap.featureFlags. This PR is necessary but not sufficient on its own — the experiment only goes green once both ship. (This PR alone still stops the localStorage poisoning and the double-counted CTA event.)

Test plan

• CI runs the PHPUnit suite (see "Local validation note"). New tests: Test_Feature_Flags, Test_Menu_Landing_Bootstrap, and bootstrap_flags cases in Test_Landing_Profile.
• Load the WCPOS welcome screen → view source: window.wcpos.landing contains bootstrap_flags: { "landing-variant": "indie" | "free-plus" }, and there is no posthog.init / posthog.identify inline script.
• Confirm the assigned variant is stable across reloads for the same site and ~50/50 across sites.
• Settings page and wc-Analytics page still emit their PostHog init snippet (regression — get_posthog_inline_script() unchanged).
• After wp-admin-landing#39 ships: new landing_variant_rendered events show render_source: flag with a ~50/50 split and a non-empty $feature_flag_response.

Local validation note

• composer run lint (PHPCS), composer run phpstan (level 5), and php -l all pass on every changed file.
• /review (correctness) and /critic (architecture) gates: both "ship it", no blocking findings.
• PHPUnit could not be run locally: wp-env could not start because Docker cannot reach the image registry in this environment (docker pull of even alpine stalls). Per project policy this is not worked around with host PHPUnit — CI is the sanctioned runner. The new tests are written to the repo's conventions and the hash logic was independently verified against a reference implementation.

Follow-ups (out of scope here)

• Infra: fix the ph.wcpos.com /flags + /decide endpoints so the public token authenticates — required for client-side flag reloads, experience-continuity, and any future experiment flag.
• Drift tripwire: the 50/50 two-arm config is hardcoded (it must be, given /flags is down). Consider a detectable server-side exposure property so a future PostHog-side config change can't silently skew the split.

Refs #1188

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Added deterministic landing-page variant feature flags and included the selected variant in the landing page bootstrap data for consistent A/B testing.

• Bug Fixes

  • Updated landing page script injection to prevent duplicate analytics initialization and remove redundant CTA click tracking from the landing inline flow.

• Tests

  • Expanded unit tests to verify landing bootstrap wiring, correct variant assignment, absence of analytics init, and no duplicate CTA tracking.
  • Added full test coverage for feature-flag resolution and overrides.